Workflow management systems (WFMS) support the modeling and execution of business processes. Business processes specify which piece of work of a network of pieces is carried out in which sequence and which resources are exploited to carry out this work. Individual pieces of work might be distributed across a multitude of different computer systems connected by some type of network.
A powerful and sophisticated workflow management system, such as the product “IBM MQSeries Workflow” supports the modeling of business processes as a network of activities. This network of activities, the process model, is constructed using a directed, acyclic, weighted, colored graph as a meta model. The nodes of the graph represent the activities, which define the individual tasks that need to be carried out. It is worth noting that any other meta model, such as a hierarchical meta model, can be used for constructing process models without departing from the spirit of the patent application. In general, each of the activities is associated with a piece of code that implements the appropriate task. The edges of the graph, the control links, describe a potential sequence of execution of the activities. Control links are represented as arrows; the head of the arrow describes the direction in which the flow of control is moving through the process.
The activity where the control link starts is called the source activity and the activity where the control link ends is called the target activity. Obviously an activity can be a source and a target activity for different control links. Activities that have no incoming control link are called start activities, as they start the process. Activities which have no outgoing control link are called end activities, as after their completion the process has ended. Obviously an activity can be start as well as end activity.
The workflow management system's internal processing of an activity is carried out as an ACID transaction, regardless whether the invoked activity implementation participates in the transaction or not. The ACID paradigm defines the set of operations carried out within a transaction features have the properties of: atomicity, consistency, isolation, and durability. Atomicity specifies that either all operations of a transaction are applied to the system or none of them are. The consistency property specifies that all operations of a collection of operations lead to a new valid state of the system. The isolation property specifies that the operations of the collection do not affect operations outside the collection. The durability property finally specifies that the operations of the collection are not undone because of any later system failure.
Probably the most typical example of a transaction is the transfer of money from one bank account to another bank account. Here, the transaction consists of two operations; the withdrawal of money from one account and the deposit of money into the other account. In this case, both operations must succeed or none of them may succeed (atomicity). As the amount of money remains the same, the new state is a valid state of the system (consistency). The new state of the two accounts is not available to any other operation, until the transaction has completed (isolation). The changes that were due to the transaction must not be lost under any circumstances (durability).
The typical transaction that the workflow management system carries out when processing an activity consists of the following steps: starting of the transaction, reading from the process engine's persistent message queue, reading process state from a database, carrying out the appropriate logic, writing any process state changes to the database, putting a message into the persistent message queue, and finally committing the transaction. Storing the process state in a database and persistent message queues and carrying out the processing as a transaction provides for the desired recoverability of the business process in case an error occurs. Details about this processing can be found in Leymann/Roller: “Production Workflow: Concepts and Techniques”, Prentice Hall PTR, 2000.
Processing pieces of code including access to data bases and message queues as a transaction is significantly more expensive than carrying out the same code non-transactional. The overhead for processing of a transaction consumes appreciable IT costs, such as CPU cycles, database access, and network and storage capacity.
The total processing overhead caused by transactional processing of the individual activities can be reduced by running a set of activities in a single transaction. The processing overhead of starting the transaction, reading the message from the persistent message queue, reading the process state from the database, writing process state changes to the database, putting a message into the persistent message queue, and committing the transaction is only performed once during the execution of the transaction that encompasses several activities. It is obvious, that by running a set of activities in a transaction the processing overhead is reduced by a factor. As a result both throughput and latency of the entire workflow management system are improved.
It should be noted that the transaction processing overhead is incurred regardless whether the invoked implementation is participating in the transaction or not.
The boundary of a transaction, the transaction boundary, is typically represented as a closed line surrounding the set of activities that are part of the transaction. The transaction is started when the first control link penetrates the transaction boundary from the outside; that means a control link whose source activity is not part of the transaction and whose target activity is part of the transaction is being followed. The transaction is committed, when the last control link penetrates the transaction boundary from within the transaction, that means a control link whose source activity is part of the transaction and whose target activity is not part of the transaction is being followed. It should be noted that outgoing control links that are transitively associated with subsequent incoming links are not taken into consideration for completing the transaction. Furthermore, the end of a transaction typically starts a new transaction with the exception of end activities. The points where the control link leaves the transaction, i.e. penetrates the transaction boundary, are also called commit points.
Combining a set of activities into a single transaction also has an important drawback. In case an activity fails, the transaction is aborted and all work already done by activities that have already run, is undone and must be redone when the transaction is restarted. This drawback must be taken into consideration when encompassing a set of activities into a single transaction, i.e. processing a set of activities as a single transaction.
In the opposite case in which each individual activity is processed as a transaction, no extra work is encountered when the activity fails. However, processing each individual activity as a transaction produces an appreciable processing overhead which is disadvantageous regarding throughput and latency of the workflow.
As defined in the prior art, the set of activities that should be processed in a single transaction need to be performed manually by a user, system administrator or process designer, quite often causing the re-structuring or re-modeling of the entire process model. Manual re-structuring is not only time consuming with required user interaction, but also depends heavily on the knowledge of the modeler. Furthermore in the prior art re-modeling or re-structuring of a process model can only be performed in a static rather than in a dynamic way, i.e. changes in the process model cannot be carried out until the modeled process has been deployed into the runtime environment.
Therefore, the present invention aims to provide a method, a data processing system and a computer program product for dynamically determining the transactions in a process model; i.e. determining the boundaries of a set of transactions that are established when the process is being carried out.